A tale of three solutions

Adam Kreczko-Lenner

A little about myself

  • Over a decade of experience

  • Career has straddled the line between architect and developer

  • Hands on with everything: architecture, technical design, development, CI/CD, and operations

  • Excellent communication skills honed by years of working in a teaching capacity

I can "talk the talk and walk the walk"

Why Enterprise Architecture?

A career spent implementing tactical solutions has taught me a lot about the importance of good strategic technology decisions

The solutions

  1. The Vendor Solution

  2. The Innovative Solution

  3. The Pragmatic Solution

The Vendor Solution

Manulife

Customer Identity and Access Management

Problem

Multiple business units, multiple logins

A lack of cohesive strategic direction across lines of business led to a disjointed user experience sign-up/sign-in

Solution

Implement a standards based single-sign-on solution leveraging OAuth, OIDC, and SAML to provide an integrated solution a cross all lines of business

How?

Purchase a vendor solution and customize to meet business requirements

Result

Major challenges in development and operations

Why?

  • Vendor product selection, solution design, and technology choices were made without regard to developer skill-sets

  • Timelines were dictated by external dates rather than internal velocity

Engineering was not a stakeholder in the decision making process

Outcome

  • Solution is functional, but difficult to maintain due to vendor "lock-in"

  • Increased cost as consultants were required to fill in skill gaps

  • Immense pressure on product team due to unrealistic timelines

  • High attrition rate of full time employees

20/20 Hindsight

  • Start with a smaller, more iterative approach

  • Keep customizations external to vendor product

  • Leverage full time employees, not consultancies

The Innovative Solution

Manulife

Group Benefits

Problem

Outdated customer facing UI with no clear path to improvement

Years of piecemeal development projects led to an inconsistent UI codebase, tightly coupled to business functionality and data

Solution

Build a generically reusable API layer to abstract away the details of the underlying data sources, and provide a flexible platform for building new user experiences

How?

Utilize Node.js and GraphQL to build a cohesive graph API, leveraging advanced techniques to dynamically integrate multiple microservices with an externalized business rule engine and authorization system

Major Contributions

Architecture

  • Designed the microservice/GraphQL based architecture

  • Developed an innovative GraphQL-based integration pattern

GraphQL Primer

What is GraphQL?

  • GraphQL is a query language for APIs and a runtime for fulfilling those queries with existing data

  • A GraphQL API consists of two main components:

    • A strongly-typed schema defining the objects and relations that make up the data graph

    • A set of custom resolving functions responsible for fetching the data required to satisfy incoming graph queries

Aggregation

  • Architecture was based around building individual GraphQL applications, scoped by bounded context, and composing them into single comprehensive API

  • Leveraged Apollo's graphql-tools which makes use of some advanced GraphQL features:

    • Introspection

    • Schema extensions

Introspection

Schema Extension

Integration

  • Developed custom library that acts as a proxy with the ability do analyze and augment incoming requests and responses

  • Library makes use of GraphQL language tools to convert queries and schemas into abstract syntax trees

Business Logic

  • Developed library to extract GraphQL schema definitions and convert them to XML schema definitions (XSD) for use in external systems

Result

Unnecessary technical complexity

Why?

  • Cutting edge technologies and techniques were used rather than more traditional approaches

  • Solution over-delivered on flexibility and functionality resulting in unnecessary costs

Technical innovation, and not business need, was the main driver

Outcome

  • Few resources fully understood the complete solution, making maintenance difficult

  • A second iteration quickly followed that kept the same overall approach and architecture, but swapped out complex components for more straightforward implementations

20/20 Hindsight

  • Listen intently to business requirements

  • Use boring technologies where possible (this is not a euphemism for Java)

  • Technical innovation is valuable, but there is a cost that must be balanced with the needs of the business

The Pragmatic Solution

Royal Bank of Canada

Direct Investing

Problem

Over the course of 15 years, RBC's Direct Investing platform had reached a state that was difficult to work with and maintain

Based on a service oriented architecture that had ballooned over time to upwards of 230 interconnected services, development work had slowed to a crawl

Business satisfaction was so low that efforts were underway to outsource all future development to an external vendor

Solution

Bring development back in-house, and improve delivery by re-writing the platform from the ground up using established industry best practices

How?

Leverage existing technological expertise by reusing internal technology stack (.Net), but utilize new architectural patterns and development techniques

Major Contributions

Architecture

  • Proposed new layered architecture based on a domain driven design

  • Architecture was vetted by Senior Architects and used as the basis for a long-term application road map

  • Assembled a curriculum to train engineers on the "whys and hows" of the new architecture and development practices

Authentication and Authorization

  • Developed components that could map from a legacy entitlements system to standard claims based authentication and attribute based access controls

  • Provided a decoupled AuthN/AuthZ layer that could be easily migrated to industry standards such as OAuth or LDAP

Caching

  • Developed a multi layered caching infrastructure that provided an easy-to-use interface available throughout the application stack

  • Component provided access to a centralized remote caching service, server-based in-memory caching, and per-request level caching

Resiliency

  • Designed and coded reusable, configurable, components to improve resiliency and robustness of the application

  • Call repeaters for retrying communication in the face of transient errors

  • Circuit breakers for "short-circuiting" calls to faulty back-end systems

Extensibility

  • Lead on a project to stand up a new Digital Investing line of business (RBC InvestEase)

  • Solution was able to leverage the new RBC Direct Investing platform for much of its functionality

Result

Success!

Why?

  • Development teams did not overreach on technology choices

  • Solution architecture and development methodologies were changed to match established best practices

  • Strong technical leadership worked with the business to ensure that expectations matched reality

Business expectations and technological delivery were well aligned

Outcome

  • Project was completed successfully after multiple, incremental deliverables over a 2.5 year timespan

  • New platform provided a better user (and developer) experience, with improved flexibility and reliability

  • Strategic goals were met when the platform was extended to support an entirely new line of business for RBC

20/20 Hindsight

  • Technical execution was not enough to ensure project success

  • It was extremely important that both business and technology teams were on the same page

Conclusion

I hope I was able to bring some broader context to the work experience outlined on my resume

I believe there is a tendency to spin all our past experiences as unmitigated successes

(even to ourselves)

But in doing so, we remove the chance to learn, grow, and see the bigger picture

I believe in my ability to execute at a technical level, but I am not blind to the bigger picture in which we operate

Thank you